I'm a little uneasy at changing where in the lifecycle the write happens - at least without an explicit opt-in for the change in behavior. Ideally, the writes can happen after save even in an import scenario.

I'd suggest looking into one of these paths:

1. Import, but with callbacks. Either a custom solution here in this gem to allow for it, or: Have you seen this? 👉 https://github.com/instacart/activerecord-import_with_callbacks/blob/main/lib/active_record/import_with_callbacks.rb

Sure, it may be a little slower than your current solution, but I'd trade a little bit of speed for more correctness (allowing for bulk inserts, but callbacks are still called after the database transaction).

2. Encrypt on set, but explicitly opt-in.

Flavor A: Add a flag to opt-in to this new behavior:

class Person < ActiveRecord::Base
  include Vault::EncryptedModel
  vault_attribute :ssn, encrypt_on_set: true  # opt-in for activerecord-import
end

Flavor B: Add an explicit encrypt method to this API

# Then, at the caller, you can explicitly write the encrypted values ahead of the import cycle:
people = 1000.times.map { |i| 
  Person.new(ssn: "123-45-#{i}").tap(&:vault_encrypt_attributes!)
}
Person.import(people)

# This is essentially just publicizing your new `__vault_write_encrypted_attribute!` interface

Any of these paths might yield leaving the default behavior as-is while still allowing for bulk import scenarios.

@chrisarcand Thanks for the ideas to leave the existing behavior intact. I was hesitant to expand the public interface at first but I think it is the right move to add an explicit encrypt method the the model.

I felt the config options like encrypt_on_set weren't suitable because the import use case shouldn't be dependent on the model definition.